Fix biparabolic regression - #2865

Thanks! Please keep the adjoint stuff so the file can then be re-used for an adjoint setup as well. With these settings, does it converge completely, can you post a plot of the residuals as function of iterations here?
The residual values reported by github are slightly different from the ones you computed yourself, you can just copy-paste the github values and update them.

Thanks! Please keep the adjoint stuff so the file can then be re-used for an adjoint setup as well. With these settings, does it converge completely, can you post a plot of the residuals as function of iterations here? The residual values reported by github are slightly different from the ones you computed yourself, you can just copy-paste the github values and update them.

Adjoint settings restored put back the adjoint, DV, and adjoint I/O options. They're inert in a DIRECT run and the regression values are unchanged with them present.

EQUIV_AREA / MARKER_NEARFIELD I left commented out, with a note in the file explaining why. I tested this specifically: with everything else identical, re-enabling them gives Warning: there are 760 non-physical points in the solution and rms[Rho] sits at +3.43 at iteration 500, versus −3.7 without them. Happy to re-enable if you'd rather the direct case carry them, but it doesn't produce a usable solution as-is.

Convergence no, it doesn't converge completely. Residuals drop quickly for ~150 iterations, then plateau around −4 and stay there. I ran it out to 3000 iterations to check: rms[Rho] was −4.05 at 2000 and −3.93 at 3000, so it's a genuine stall rather than slow progress. Plot below.

That convergence doesn't look good. Also, the equivalent area and nearfield conditions are important parts of this setup so I think it is best to keep those, since we already have a bunch of testcases that test the standard euler flow with a farfield BC. That probably means tinkering a bit with the settings to find out how to make it converge well.

That convergence doesn't look good. Also, the equivalent area and nearfield conditions are important parts of this setup so I think it is best to keep those, since we already have a bunch of testcases that test the standard euler flow with a farfield BC. That probably means tinkering a bit with the settings to find out how to make it converge well.

I dug into the nearfield setup and I think the problem is deeper than config settings. Findings, all tested with everything else held constant:

MARKER_NEARFIELD alone (with EQUIV_AREA= NO) gives 760 non-physical points and rms[Rho] = 3.4319. Enabling EQUIV_AREA= YES on top gives bit-identical results, so the EA post-processing isn't involved it's the nearfield BC itself.
Without the nearfield markers, rms[Rho] reaches −3.9 with no warnings.
I also corrected EA_INT_LIMIT from (-100, 100, 2.0) to (1.562, 4.562, 2.0) to match the actual nearfield extent in the mesh no effect on the solution.
In the mesh, upper_nearfield and lower_nearfield are coincident duplicate nodes, both on the line y = −2 with bit-identical x-coordinates (e.g. node 8 and node 56581 are both at x = 1.562149913, y = −2.0). So this is an internal interface construction rather than two surfaces above and below the airfoil.
The one working EA case in the suite, ea_naca64206, is 3D with a circumferential nearfield surface, which matches what config_template.cfg describes as required.

So this looks like the 2D coincident-node nearfield path being broken rather than a settings issue probably needs a look at the nearfield BC implementation. Happy to keep going if you can point me at the relevant code, or to close this if you'd rather handle it separately.